Multimedia is nowadays ubiquitous in the Internet and many web applications that are already based on HTTP are utilizing this protocol for multimedia streaming.
For example, multimedia streaming is conducted by adopting progressive download Netflix, Hulu and Vudu, which are just a few prominent examples, which have deployed their streaming service over the top. Interestingly, this streaming approach works pretty well, which implies that the assumption of former video streaming research, that streaming on top of the Transmission Control Protocol (TCP) will not work smoothly due to its retransmission delay and throughput variations, could be seen as an illusion. Furthermore, HTTP streaming has some advantages compared to traditional streaming approaches, which are mainly based on the Real-Time Transport Protocol (RTP) and the User Datagram Protocol (UDP). The HTTP architecture is well deployed and the protocol is widely accepted. Therefore it is possible to traverse Firewalls and handle Network Address Translation (NAT) without any configuration effort, which is one of the major advantages of HTP streaming. However there are certain disadvantages when using HTTP and as a consequence TCP for multimedia streaming. In particular, the combination of TCP and HTTP introduces a significant overhead compared to RTP, which commonly uses UDP as carrier protocol (see [13]).
Another disadvantage is the inflexibility in case of varying bandwidth conditions which are common in networks that are based on the Internet Protocol (IP). Therefore, ISO/IEC MPEG has recently ratified an advancement of that basic HTTP streaming approach. which is referred to as Dynamic Adaptive Streaming over HTTP (DASH, see [3]). In comparison to traditional HTTP streaming, this approach is able to handle varying bandwidth conditions while maintaining its advantages, such as NAT/firewall traversal and flexible deployment. Additionally, major industry players including Microsoft (see [14]), Apple (see [15]), and Adobe (see [16]) have deployed their proprietary solutions and interestingly all of them are based on the same principle, which means that the streaming logic is located al the client side and multiple versions of the content, e.g., different resolution, bitrate, language, codec etc. have been segmented and stored on ordinary webservers.
FIG. 5 depicts a DASH streaming scenario and the behavior of the client. The control server provides three qualities, namely best, medium and low that the client could select according to its available bandwidth. Considering such a scenario the first request of the client would be for the so-called Media Presentation Description (MPD). The MPD describes the temporal dependencies of the segments, the capabilities e.g. resolution, codec, bitrate, language etc. and the location of each segment. This information is needed by the client so that it could request the individual segments that fit to its bandwidth requirements or user preferences. In case of a live session the client would have to update the MPD in given intervals so that it gets the location and capabilities of the newly generated segments. As shown in FIG. 5, after the client has downloaded and analyzed the MPD it cloud start to request the segments that fit to its bandwidth conditions.
In FIG. 5 at the beginning, where the client requests two segments of low quality, according to the bandwidth conditions. Afterwards, it adapts to the available bandwidth and switches to a higher quality level i.e. best.
Streaming approaches that are utilizing cloud services are currently very popular, due to the fact that the whole streaming service could be offloaded to a cloud.
In general, one or more servers may be considered as a cloud. For example, a server system comprising one or more servers can be considered as a cloud.
The above-described offloading and using software more as a service, than something that is locally installed, seems to be an interesting principle, especially for mobile devices, due to their limited hardware and storage capacities. Nevertheless, such a cloud streaming architecture introduces also some new challenges, for the simple reason that the software or multimedia content will now be requested from the cloud through the internet but the user expectations in case of Quality of Experience (QoE) i.e. low startup delay, smoothness (see [1]) etc. should not differ between playing a locally and remotely stored media file.
This is in particular a problem for mobile devices, which are often connected to the internet through an interface with high bandwidth fluctuations.